This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
- I have (hopefully) only ever said (in this thread) that XPages are a complete no-go for migrating complex legacy applications, implying retention of legacy code. I've indicated they could be the cat's meow for *new* development, which would include (perhaps incorrectly) a complete rewrite of a legacy application to use the XPages model.
- I know XPages are the future. I didn't know, when I started, that XPages were a complete disconnect from the past, because every single blog, forum post, and wiki I could find indicated how XPages work so well with legacy code. Bull. XPages suck with legacy code in a way that makes a daily enema look pleasant.
- I also have stressed complexity many times. My code is 25,000 lines of OO class hierarchy that I wanted to keep, rather than rewrite. With all the time I've wasted on the non-compatibility with legacy code, I could have rewritten all that code. But I was led to believe XPages work, and I can keep my code, so I went down that path. Now it's so late in the game I can't turn around. I don't want someone else to get stuck. I want them to avoid XPages, or rewrite their legacy application from scratch. Those are the only viable options.
That is all I am and hopefully all I ever have said in this thread, which was started by someone asking why use XPages for legacy migration. The answer is don't.
Feedback response number DGIE85THRL created by ~Holly Zekhipisonnivu on 05/26/2010
I agree completely!
Return to top
. . . . . . . . . . . . I agree completely! (~James Brewever... 26.May.10) 
